【万泉河】【博途】对待库的正确姿势

上个月，接到分享贴征集令： 说说我用过的TIA博途的功能块

希望我也贡献一篇。 我本来已经动笔在写了，可后来，因为忙着出差以及其他的一些事情，写了一半，就放下了。 出差回来，看到网站上已经在进行优秀文章评比了。 赶不上了，但还是补充完善，把文章发出来。 还好，虽然评奖是过时了，但技术不过时，观点也不会过时。
 

下面是正文：

说实话， 我看到题目是懵逼的。
     

不知道在要求什么。
     

是要我分享自己做的功能块呢， 还是分享使用经验呢？
     

反复把要求读了好几遍，最后确认要求还是后者。
     

但目前的博途来说，系统根本没有内置什么专用的行业应用库，所谓的功能块， 还是具体针对某一个功能的。
     

比如对PID，有专门的PID块。 各种通讯，有专门的通讯的FB/FC块。

那有什么好分享经验的呢？分享的话， 无非要你描述下这个功能的实现过程而已！你压根就没得选， 会使用这个功能块，      才能实现想要的功能。 不会使用，就实现不了。
     

我猜，大多数人又会把精力放在PID或者通讯的功能块的经验分享上面。 因为那是大家都能想到的最贴近题目要求的功能块。
     

但是，分享了通常是白白分享。 只有用得到相关功能的读者才会感兴趣。 永远没机会用到这个功能的， 恐怕也看不懂，      就只能先收藏以后用到时再看了。 会比手册更受用吗？

不得而知。
     

所以， 我情愿认为， 还是想要大家分享自己封装的功能块。即所谓库。
     

但，工控行业，养成了分享的习惯了吗？

没有。 远远没有。
     

看看我发起的一个投票帖的投票情况就知道了。
     

工控人士的分层， 你在哪一层？http://www.ad.siemens.com.cn/club/bbs/post.aspx?a_id=1515437&b_id=66&s_id=84&num=21#anch

75%的工控人士，压根不知道Github的存在，更不会知道其运转模式，何来分享？

• 真的要分享观点和经验的时候， 哪怕要分享一个理念，都会被曲解，谩骂，          甚至发展到批斗。
         

• 这都是一群什么样的智商和情商的人？

• 我告诉他们什么样的程序不好， 烂。他们对照一看自己做的程序符合这个标准，          立马推论到自己是个烂人， 然后就认为我是骂他们了。 
   

所以， 目前的行业的状况， 有价值的知识也只适合在小范围的社区内分享。 有志之士共同分享。
     

下面的分享只是纲要， 具体的细节，会在PLC标准化编程技术社区中与学员们详细探讨。
     

进入正题：

1，何谓库

库的一个基本特征是，可有可无。一个工艺过程，可以直接用逻辑搭出来。 但为了便于重复例用， 或者标准化的目的， 可以做成标准的库。

打个比方，对于自动化项目中最常见的电机水泵的控制， 就有BST例程等各种封装的库， 对应的WINCC的画面模板配合使用，相当精致。
     

为了标准化兼容性的目的， 可能会导致库的内容做的比较全面，各种接口各种参数考虑得比较充分，
     

但同时也导致使用库函数的PLC运行效率比较低。 甚至有可能因为增加了太多无用的功能， 浪费了太多系统资源， 导致PLC性能不足。

两种处理办法：要么升级CPU， 换高性能的型号。

要么就是精简库函数， 砍掉库函数中对当前项目多余的功能和数据。

2，对待库的方法

不管是自己以前做好的库，      还是别人分享的库，当然前提是已经印证逻辑稳定可靠的基础上，可以使用的措施有：

• 直接使用

• 升级使用

• 修改使用

• 封装继承
     

系统应用千差万别，已有的现成的库能拿来简单直接使用，当然欢喜。 但大部分情况下， 是没有那么容易如愿的。
     

举个例子，比如前面提到的电机的标准控制模块已经有了。 而新项目中有电机是需要正反转控制的，  就可以有上面列出的不同的使用方式了：

直接使用：把电机的正反转当成2个电机， 通过程序逻辑的互锁， 实现2个实例之间的保护。但在上位机上面， 就需要有2个控制模板，一个对应了电机的正转，另一个对应了电机的反转，这在大多数情况下，操作员会懵逼的。
 

升级使用：把原有的库函数改掉，增加反转功能， 已有的设备， 哪怕只有正转功能而不需要反转， 也仍然调用，无非反转功能的接口留空。 我们看到大部分的库函数， 有很多用不到的功能，都是这个思路来的。 尤其是PCS7。 你会看到一个简单的设备， 会多出来无数没用的接口， 简直不明所以。
 

修改使用：在原有库函数基础上，另存生成一个新的库函数， 上位也另存生成一个新的对应的模板。这应当是影响最小的方式，但库的类型多了， 占用的各种系统资源也多了。 而且，如果有一天，母体的库函数升级了， 这些衍生出来的库函数也需要随之逐个升级，是一个不小的工作量。 极易出错。

封装继承：理论上来说，为了克服上一条的缺点，可以对母体库函数封装，建立一个新的库函数，调用母体的库函数。但很可惜，目前来看还只是理论。在软件行业很通常的做法，在PLC系统，可操作性还很差。 即便最新的portal V15.1。
 

*************

这一篇因为时间跨度2个月，思维断了有些接不上岔，所以整理一下草草结束。 以后有机会一些细节再继续阐述。 有疑问的读者可以单独问我，跟我讨论。
 

总之，对于库的使用，对于标准化编程， 需要交待的事情很多，观点也很繁杂。 我正在组织的标准化编程技术社区， 预期在2019年1月份，就可以开班了。 大雪纷飞的时节，不再安排出差， 不再去现场挨冻。 就在家里，在电脑前，和大家愉快地分享最前沿的技术成果，应当是一件相当幸福的事。

已经报名的小伙伴们，可以筹款付款了。
 

还没报名的，有兴趣参加的朋友们，赶紧联系报名啦！

详情参见：

或加微信：178616417后咨询。